A method of the aforementioned kind is described in US patent application US-A-2010/0007311. This application relates to a battery module comprising cells, two external connections, a message-communication-infrastructure, a module control unit with a message processing unit that is connected to the infrastructure in order to send and receive messages. A method is described for transmitting data between a control device and modules via a CANopen bus. Data is transmitted by using a service data object as a SDO service. In this configuration the modules and the control device function as the SDO client.
The US patent application US-A-2005/0002417 relates to systems and methods for executing protocol conversions in an environment, comprising a work machine with one or more modules that are coupled to one another via one or more data connections. Such systems and methods can have one or more gateways for executing “tunneling” or “bridging” operations. “Tunneling” processes can include receiving a message from a source module in a first protocol, decapsulating the messages in the transmission units of a second protocol and transmission of the decapsulated message via the second protocol.
CANopen was developed by the CiA (CAN in Automation), a user and manufacturer's association for CANopen, and available as European Standard EN 50325-4 since the end of 2002. CANopen utilizes as transmission technology the layers 1 and 2 of CAN standard (ISO 11898-2) originally developed for use in automobiles.
In CANopen, several basic services (service primitives) are defined. These basic services are:                Request: Request of a CANopen service by an application        Indication: Report to the application that a result or a specific message is present        Response: Response of the application to an indication        Confirmation: Confirmation to the application that a CANopen service has been executed.        
The manner in which CANopen devices exchange data with one another is regulated via a CANopen communication profile. As with all other field bus protocols, a distinction is made between real-time data and parameter data. CANopen assigns suitable communication elements or communication objects to each of these data types, which are completely different in character.
The communication objects can be subdivided as follows:                Service data objects (SDO) for parameterizing device object dictionary entries        Process data objects (PDO) for transporting real-time data        Network management objects (NMT) for status control of the CANopen device and for account monitoring,        additional objects such as synchronization objects, time stamping and error messages.        
All communication objects and all user objects are compiled in an object dictionary (English: Object Dictionary (OD)). The object dictionary in the CANopen device model is the link between the application and the CANopen communication unit. Each entry in the object dictionary stands for an object and is characterized by an index, such as a 16-bit index. An index can in turn contain up to 265 subindicies. In this way it is possible, independent of the “11-bit identifier”, to differentiate up to 65.536×254 elements.
In the communication profiles the allocation of communication and device object profiles for a respective index is precisely defined. Thus, the object dictionary defines a distinct interface between the application and the outward communication. For example, for each CANopen node in the network it is known that the “heart beat interval” is found at index 1017 h, and any node or any configuration program has read or write access to it.
For each communication object there exists a distinct COB-ID (communication object identifier) in the network. The CO-ID consists of 32 bit values, in which each of the first two bits can have an object-specific meaning In an 11-bit CANnetwork the following 19 bits (29 to 11) have the value 0 and the last bits (10 to 0) correspond to the CAN identifier.
Service data objects (SDO) provide a service for accessing the object dictionary. Each CANopen device requires at least one SDO server which receives and processes requests from other devices. The default settings utilize messages to the SDO server of a device, the node number of the receiver plus 1536 as COB-ID or as “identifier” for the CAN message. The node number of the transmitter plus 1408 is used as “identifier” for the response by the SDO server. These relatively high, and thus low prioritized, IDs are used to transfer entries into the object dictionary. A protocol for this SDO transfer exists which requires, for example 4 bytes in order to encode the direction of data transfer, the index and the subindex. Hence, only 4 bytes of the 8 bytes of a CAN data field remain for data content. For objects that are larger than 4 bytes there are two additional protocols for fragmented transfer of data.
In contrast to the prioritized SDO transfer overloaded with protocol data, the process data object (PDO) provides a faster option for transferring process data.
The identifiers used for PDO transfer for the default settings are in the COB-ID range of 385 to 1407, and are therefore prioritized higher than the SDO messages. In addition, they only contain user data, hence 8 bytes are available.
The content of the user data is determined via PDO mapping entries. These are objects in the object dictionary which, like an allocation table, determine which data are transmitted via a PDO. This data is in turn the content of other objects of the object dictionary. In a PDO the values of multiple objects may also be transmitted and the receivers of the PDO can in accordance with their PDO mapping entries utilize only parts of the data.
Once a PDO is received the data are in turn written, respectively, in other objects of the object dictionary in accordance with the mapping entries, for example, in a digital output object. PDOs can be transmitted cyclically, event-oriented, per request or synchronized.
The MODBUS protocol is a communication protocol based on a master-slave or client-server architecture. It was developed in 1979 by Gould Modicon for communicating with programmable logic controllers. The MODBUS, since it is an open protocol, has become a de facto standard in the industry.
A master, for example, a PC and multiple slaves (for example, measurement and control systems; field devices) can be connected by means of MODBUS. There are two versions: one for the serial interface (EIA-232 and EIA-485) and one for Ethernet.
In data transmission a distinction is made between three different types of operations:                MODBUS ASCII        MODBUS RTU        MODBUS TCP.        
Each bus device must have a specific address.
CANopen, MODBUS, PROFIBUS and Ethernet-based networks are used in automation technology to establish communication between data processing systems and peripheral devices. For example, programmable logic controllers (PLC), fieldbus couplers, IO/-modules, drive controllers (motion controllers), display devices are coupled to one another over a local network (field bus). Field devices that are linked to a MODBUS include a MODBUS interpreter in order to interpret the MODBUS messages transmitted over MODBUS.
As a general rule, prior art systems and methods enable parameterization of field devices by means of configuration files, in which certain predefined functionalities of the respective device, depending on the need and the range of application of the device, can only be switched on or off, or are activated or deactivated.
Parameterization and/or configuration usually occurs by way of a direct connection between a data processing device such as a PC (personal computer), laptop or PDA (personal digital assistant) and the field device by transmitting a MODBUS message which can be interpreted in the field device. The configuration of each individual field device via a one-to-one connection is costly and time consuming.
When using a field device of this type with a MODBUS interface in a CANopen fieldbus, the problem arises that the CANopen messages cannot be evaluated by the MODBUS interface.
On the other hand, application data and application parameters of a CANopen device are present as objects in the CANopen that are stored in the CANopen object dictionary.
If an application requires more data/parameters than are present in the CANopen object dictionary, it is impossible to access such information via a CANopen network.
Based on the foregoing, the object of the present invention is to further develop a method of the aforementioned kind that simplifies the configuration of field devices to CANopen.
The object is achieved in accordance with the present invention inter alia in that the method is used for configuring and/or parameterizing via the CANopen bus the at least one second automation device that includes a MODBUS server, in that the data are generated as configuration and/or parameterization data in the form of a MODBUS frame and are encapsulated in the CANopen frame, and in that the CANopen frame is loaded by means of a SDO-download into the data tunnel object of the SDO server of the at least one second automation device and is decapsulated.
The method according to the present invention makes it possible to encapsulate messages such as MODBUS messages in a CANopen message. The encapsulation or tunneling of device-specific data, such as configuration and/or parameterization data enables automation devices to be configured via the CANopen bus from a central location such as a user PC or central controller, which only have access to an interface different from CANopen, such as a MODBUS interface for processing the device-specific data, and which according to the prior art would have to have been configured via a one-to-one connection.
The method according to the present invention can thus be utilized to configure and/or parameterize by way of a CANopen bus field devices that include a MODBUS server, wherein configuration and/or parameterization data are encapsulated as a MODBUS frame in a CANopen frame, which is loaded by means of a SDO-download into the data tunnel object of a field object and decapsulated.
A preferred method is distinguished by the fact that a data transmission is carried out from the first automation device to the at least one second automation device by way of a SDO download to a data tunnel object of the object dictionary, initiated by the application implemented in the first automation device.
According to another preferred method, it is provided that data transmission is carried out from the at least one second automation device to the first automation device by way of a SDO download to a data tunnel object of the object dictionary, initiated by the application implemented in the first automation device, wherein the application addresses cyclically the application in the at least one second automation device.
To transmit data, a preset SDO server channel can be preferably used, whereby a second SDO server channel is used if the transmission rates of encapsulated data are high.
The method is further distinguished by the fact that a single data tunnel object is sufficient for simplex or half-duplex data transmission. For full duplex data transmission at least two data tunnel objects are used in the object dictionary of the SDO server.
For parameterizing and/or configuring field devices by way of a CANopen bus, it is provided that the application implemented in the first automation device comprise a field device tool and at least one device type manager which are used to generate parameterization and/or configuration data in the form of a MODBUS frame, that the MODUBUS frame is encapsulated in a CANopen frame and that the CANopen frame is transmitted by means of a SDO download into the data tunnel object of the SDO server of the at least one second automation device.
When transmitting data from the at least one second automation device to the first automation device, it is necessary for a protocol-specific part of the device type manager implemented in the first automation device to regularly query the at least one second automation device with the application, wherein a CANopen communication DTM implemented in the application executes the SDO upload request.
The data tunnel object is preferably domain type.
To transmit data to a plurality of field devices linked to a CANopen bus, the CANopen frame with the encapsulated MODBUS frame is sent via a routing functionality implemented in the first automation device to the at least one second automation device with the appropriate address.
As encapsulated data, it is preferable to send parameter and/or configuration data in addition to control programs.
Data can be transmitted sequentially for each of the two automation devices and/or transmitted when one of the two automation devices is connected to the CANopen bus.
Further details, advantages and features of the invention are set forth in the claims, the features by themselves or in combination taken therefrom, as well as preferred embodiments taken from the following description of the drawings.